Software systems may be extended through the use of smart item (also referred to as smart device), technologies, in which physical items (e.g., goods, tools, rooms, vehicles, persons, or shelves) are augmented or enhanced by the addition or inclusion of locally-provided or embedded technology. For example, radio-frequency identification (RFID) systems, embedded systems, sensor motes, and/or wireless sensor networks may be used in the above-described manner to provide business software applications with fast access to real-world data. In many instances, for example, smart items may include, or may be associated with, devices having local processing power, memory, and/or communication capabilities, and that are capable of providing data about the device and its properties, or information about a current state or environment of the smart item devices. Accordingly, for example, some such devices may be used in the execution of service components of back-end or underlying business applications, and, in particular, may do so in a collaborative way, e.g., by forming mobile ad-hoc networks to collect, process, or transmit business data.
Examples of smart items may include an RFID tag, which may be passive or active, and which may be attached to a physical object, as referenced above, and used to provide product or handling information related to the object. Other examples of smart items may include various sensors, such as, for example, environmental sensors (e.g., a temperature, humidity, or vibration sensor), which, as just referenced, may be capable of communicating to form one or more sensor networks. These and other types of smart items also may include embedded systems, which may refer generally to any system in which a special-purpose processor and/or program is included, and/or in which the system is encapsulated in the device being controlled.
Deployment of such devices may be constrained in several respects, including, for example, amounts of available processing power, energy, or bandwidth. For example, when networks of nodes are deployed across a physical location(s), the nodes may have insufficient transmission power or range to communicate directly with one another, or with a base station, in a single hop. Consequently, the nodes may relay communications to, in this example, a base station, by way of an intermediate node on the network, i.e., may use a multi-hop path.
However, due to the energy constraints just referenced, the nodes are not typically enabled to transmit data continuously, or whenever new data becomes available (e.g., whenever a sensor detects a new event or condition). Instead, the nodes are often programmed to save their data for intermittent transmission, and to otherwise stay in a sleep or low-power mode, during which no transmission occurs. A relation of the time during which the node is active (and transmission occurs) to the time during which the node is passive (and no transmission occurs) is often referred to as a duty cycle of the node. Thus, selection of the duty cycle reflects a trade-off between, for example, energy conservation and transmission delays. Further, when transmissions occur via the multi-hop paths referenced above, then coordination may be required between, for example, the node which generates the data and the relaying or intermediate node that re-transmits the data, for example, to a base station.